1. Technical Field
The present invention relates to an object oriented simple persistence mechanism for effectuating data transfer between a software application and a relational database.
2. Related Art
Object oriented programming systems typically use persistence mechanisms to mediate between Enterprise Java Beans® software applications and relational databases such as DB2®. A persistence mechanism is generic software which functions as an interface and data transfer mechanism between the software application and the database for storing and retrieving data to and from the database. Prominent related art persistence mechanisms include: 1) Persistence Builder by Visual Age; and 2) Enterprise Java Beans® by Sun Microsystems®.
Persistence Builder has been viewed for many years as the persistence mechanism of choice. After introduction of Enterprise Java Beans®, however, the J2EE architecture called for the use of Enterprise Java Beans® in conjunction with servlets or Java Server Pages as the way to develop server based web applications (e.g., applications running under WebSphere®). Nonetheless, both Persistence Builder and Enterprise Java Beans® are deeply flawed and unsuitable for use “as is” in a WebSphere environment. The transaction management provided by Persistence Builder and Enterprise Java Beans® will not function in a clustered WebSphere environment. Enterprise Java Beans® require that each database interaction be broken into a “client” and “server” piece. The interface between the client and server needs to be structured to support an extremely inefficient interface (i.e., remote method invocation or RMI) between the client and server. When the result of a database query is returned by the Enterprise Java Beans® mechanism, only a list of keys to the retrieved objects is returned. A separate call to the database has to be issued to instantiate the bean, and then separate calls need to be issued through a succession of client and server stubs for the individual ‘get’ methods for each column value. When an Enterprise Java Beans® ‘set’ method is called, it actually issues an individual database update call for that individual column. This severe inefficiency has made Enterprise Java Beans® very unpopular with web developers.
PersistenceBuilder is somewhat more efficient than Enterprise Java Beans®, and has been fairly widely used. As explained supra, Enterprise Java Beans® do not offer a suitable alternative. PersistenceBuilder has its own problems, mainly its attempts at transaction management which are totally inadequate for a clustered environment (i.e., the transaction information is held in memory on one server, so once an interaction crosses servers it loses all integrity).
There are also numerous failings in both Persistence Builder and Enterprise Java Beans®. Neither provides a way to limit the number of rows returned by a database query, although this is part of the Java JDBC specification. PersistenceBuilder does not provide a way to add search criteria for a query, and adding search criteria for a query is cumbersome using Enterprise Java Beans®. Both Persistence Builder and Enterprise Java Beans® generate large amounts of data handling code with separate classes for each table and separate ‘get’ and ‘set’ methods for each column in the table. This code is voluminous and gets in the way of any high level processing.
Both Persistence Builder and Enterprise Java Beans® offer to developers the ability to lay out the database schema and to set up relationships among the tables in the database. However, there are performance penalties in the code that processes these relationships that can outweigh the buildtime convenience and there are runtime headaches.
Therefore, there is a need for a persistence mechanism that mitigates or eliminates the aforementioned problems associated with the related art persistence mechanisms.